Testing telecommunication services can be a laborious and time-consuming task. This is especially true in today's environment where a wide variety of new telecommunication services are being deployed on a rapid basis. Further, the increased use of intelligent network elements including automation devices such as audio response units (ARUs), and intelligent switches such as automatic call distributors, complicate the task of testing new telecommunication services. Telecommunication services are typically tested and re-tested at various stages throughout the development process.
For example, as new services are being developed they are typically modified and refined on a frequent basis. The modifications are generally based on several factors including marketing studies, customer feedback, hardware and software design changes, and network element changes. To implement such modifications during the development cycle, product development organizations modify the software that drives the various network elements used to support the new service. The modified software versions are then released to testing organizations that are responsible for verifying the functionality and performance of the new service. Accordingly, during a typical product development cycle, many different software versions may be released to the testing organizations as the features and functions of the new service evolve.
Thus, testing organizations typically perform many iterations of various test activities to verify that new services operate as designed and do not adversely affect existing telecommunication services. The dynamic nature of the development of new services, and the time-to-market pressures imposed upon the telecommunications industry, drive the need for timely and efficient test procedures.
Often these requirements are met by automating test procedures. Once test cases are automated they can be repeated with minimal effort. This automation facilitates regression testing, which verifies common features among different software versions. In addition, automated test cases are generally more reliable than manual test cases due to the reduction of human factor errors. Further, automated test systems are more efficient and reliable because they execute test cases repeatedly in exactly the same manner.
However, in order to gain the maximum benefit from automation, test cases must be designed for execution without human interaction. This not only reduces test staff requirements, but also enables one to run test cases continuously during the day or night. In order for test cases to run unattended, they must be able to verify the correct operation of telecommunication services and they must be able to detect errors when they occur. Typically, test cases are designed to accomplish this by dynamically comparing the test case results against predefined expected results. Alternatively, test cases can be programmed to generate test result logs or the like, which can be analyzed at a later time.
In addition, in order for test cases to run unattended, the telecommunication service under test must not require human interaction. For example, telecommunication services such as voice mail systems, automated collect call services and the like, generally require human interaction. Human interaction can be in the form of speech and/or telephone keypad input. As such, testing these types of telecommunication services are conventionally performed manually.
Another difficulty arises when testing telecommunication services that include the use of manual operators. Typically such services involve human operators interacting with customers from manual operator consoles. The very nature of such human interaction makes the testing of such service inherently difficult to automate. Thus, these types of services are also conventionally tested manually. Moreover, today's hardware is increasingly dependent upon and tightly coupled with software that enables many of the features that consumer's demand. As the software and hardware are joined, the complexity of the software components and the difficulty of testing the union of the software and the hardware has increased in complexity.
Former software and hardware development tools included editors, debuggers and a lot of programmer sweat time. With the complexity of modern software and hardware, and the many possible scenarios that must be tested to assure proper system function, it is necessary to replace older, primitive tools with a testing system that is flexible and capable of testing many, diverse permutations of software enabled hardware features.